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Abstract 


This document specifies how to use Elliptic Curve Digital Signature 
Algorithm (ECDSA) with XML Signatures. The mechanism specified 
provides integrity, message authentication, and/or signer 
authentication services for data of any type, whether located within 
the XML that includes the signature or included by reference. 
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1. Introduction 


This document specifies how to use the Elliptic Curve Digital 
Signature Algorithm (ECDSA) with XML signatures, as specified in 
[XMLDSIG]. [XMLDSIG] defines only two digital signature methods: RSA 
and DSA (DSS) signatures. This document introduces ECDSA signatures 
as an additional method. 


This document uses both XML Schemas [XML-schema] (normative) and DTDs 
[XML] (informational) to specify the corresponding XML structures. 


2. ECDSA 


The Elliptic Curve Digital Signature Algorithm (ECDSA) is the 
elliptic curve analogue of the DSA (DSS) signature method 
[FIPS-186-2]. It is defined in the ANSI X9.62 standard [X9.62]. 
Other compatible specifications include FIPS 186-2 [FIPS-186-2], IEEE 
1363 [IEEE1363], IEEE 1363a [IEEE1363a], and SEC1 [SEC1]. [RFC3279] 
describes ways to carry ECDSA keys in X.509 certificates. 
[FIPS-186-2], [SEC2], and [X9.62] provide recommended elliptic curve 
domain parameters for use with ECDSA. 
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Like DSA, ECDSA incorporates the use of a hash function. Currently, 
the only hash function defined for use with ECDSA is the SHA-1 
message digest algorithm [FIPS-180-1]. 


ECDSA signatures are smaller than RSA signatures of similar 
cryptographic strength. ECDSA public keys (and certificates) are 
smaller than similar strength DSA keys and result in improved 
communication efficiency. On many platforms, ECDSA operations can be 
computed faster than similar strength RSA or DSA operations (see 
[KEYS] for a security analysis of key sizes across public key 
algorithms). These advantages of signature size, bandwidth, and 
computational efficiency may make ECDSA an attractive choice for 
XMLDSIG implementations. 


3. Specifying ECDSA within XMLDSIG 
This section specifies how to use ECDSA with XML Signature Syntax and 
Processing [XMLDSIG]. It relies heavily on the syntax and namespace 
defined in [XMLDSIG]. 

3.1. Version, Namespaces, and Identifiers 
This specification makes no provision for an explicit version number 
in the syntax. If a future version is needed, it will use a 


different namespace. 


The XML namespace [XML-ns] URI that MUST be used by implementations 
of this (dated) specification is: 


http://www.w3.org/2001/04/xmldsig-more# 
Elements in the namespace of the [XMLDSIG] specification are marked 
by using the namespace prefix "dsig" in the remaining sections of 


this document. 


The identifier for the ECDSA signature algorithm as defined in 
[Eastlake] is: 


http://www.w3.org/2001/04/xmldsig-moreffecdsa-shal 
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3.2. XML Schema Preamble and DTD Replacement 
3.2.1. XML Schema Preamble 


The subsequent preamble is to be used with the XML Schema definitions 
given in the remaining sections of this document. 


<?xml version-"1.0" encoding-"UTF-8"?> 

<xs:schema 
targetNamespace="http://www.w3.org/2001/04/xmldsig-more#" 
xmlns:ecdsa="http://www.w3.org/2001/04/xmldsig-more#" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified" attributeFormDefault="unqualified" 
version="0.2"> 


3.2.2. DTD Replacement 


To include ECDSA in XML-signature syntax, the following definition of 
the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 


<!ENTITY $ KeyValue.ANY r| ecdsa:ECDSAKeyValue’ > 
3.3. ECDSA Signatures 


The input to the ECDSA algorithm is the canonicalized representation 
of the dsig:SignedInfo element as specified in Section 3 of 
[XMLDSIG]. 


The output of the ECDSA algorithm consists of a pair of integers 
usually referred by the pair (r, s). The signature value (text value 
of element dsig:SignatureValue - see section 4.2 of [XMLDSIG]) 
consists of the base64 encoding of the concatenation of two octet- 
streams that respectively result from the octet-encoding of the 
values r and s. This concatenation is described in section E3.1 of 
[IEEE1363]. 


3.4. ECDSA Key Values 


The syntax used for ECDSA key values closely follows the ASN.1 syntax 
defined in ANSI X9.62 [X9.62]. 


3.4.1. Key Value Root Element 
The element ECDSAKeyValue is used for encoding ECDSA public keys. 
For use with XMLDSIG, simply use this element inside dsig:KeyValue 


(such as the predefined elements dsig:RSAKeyValue or 
dsig:DSAKeyValue). 
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The element consists of an optional subelement DomainParameters and 
the mandatory subelement PublicKey. If Domainparameters is missing, 
the application implicitly knows about it from other means. 


Schema Definition: 


<xs:element name="ECDSAKeyValue" type-"ecdsa:ECDSAKeyValueType"/> 
<xs:complexType name="ECDSAKeyValueType"> 
<xs:sequence> 
<xs:element name-"DomainParameters" type="ecdsa:DomainParamsType" 
minOccurs="0"/> 
<xs:element name="PublicKey" type="ecdsa:ECPointType"/> 
</xs:sequence> 
</xs:complexType> 


DTD Definition: 


<!ELEMENT ECDSAKeyValue (DomainParameters?, PublicKey)> 
<!ELEMENT PublicKey (X, Y)?> 

<!ELEMENT X EMPTY> 

<!ATTLIST X Value CDATA #REQUIRED> 

<!ELEMENT Y EMPTY> 

<!ATTLIST Y Value CDATA #REQUIRED> 


3.4.2. EC Domain Parameters 


Domain parameters can be encoded either explicitly using element 
ExplicitParams, or by reference using element NamedCurve. The latter 
simply consists of an attribute named URN, which bears a uniform 
resource name as its value. For the named curves of standards like 
[X9.62], [FIPS-186-2], or [SEC2], the OIDs of these curves SHOULD be 
used in this attribute, e.g., URN="urn:o0id:1.2.840.10045.3.1.1". The 
mechanism for encoding OIDs in URNs is shown in [RFC3061]. 


Schema Definition: 


<xs:complexType name="DomainParamsType"> 
<xs:choice> 
<xs:element name="ExplicitParams" 
type="ecdsa:ExplicitParamsType"/> 
<xs:element name="NamedCurve"> 
<xs:complexType> 
<xs:attribute name="URN" type-"xs:anyURI" use-"reguired"/> 
</xs:complexType> 
</xs:element> 
</xs:choice> 
</xs:complexType> 
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DTD Definition: 


<!ELEMENT DomainParameters (ExplicitParams NamedCurve) > 
<!ELEMENT NamedCurve EMPTY> 
<!ATTLIST NamedCurve URN CDATA #REQUIRED> 


The element ExplicitParams is used for explicit encoding of domain 
parameters. It contains three subelements: FieldParams describes the 
underlying field, CurveParams describes the elliptic curve, and 
BasePointParams describes the base point of the elliptic curve. 


Schema Definition: 


<xs:complexType name="ExplicitParamsType"> 
<xs:sequence> 
<xs:element name="FieldParams" type="ecdsa:FieldParamsType"/> 
<xs:element name="CurveParams" type="ecdsa:CurveParamsType"/> 
<xs:element name="BasePointParams" 
type="ecdsa:BasePointParamsType"/> 
</xs:sequence> 
</xs:complexType> 


DTD Definition: 
<!ELEMENT ExplicitParams (FieldParams, CurveParams, BasePointParams) > 
3.4.2.1. Field Parameters 
The element FieldParams is used for encoding field parameters. The 
corresponding XML Schema type FieldParamsType is declared abstract 
and will be extended by specialized types for prime field, 
characteristic two field, and odd characteristic extension fields 


parameters. 


The XML Schema type PrimeFieldParamsType is derived from the 


FieldParamsType and is used for encoding prime field parameters. The 
type contains the order of the prime field as its single subelement 
P. 


The XML Schema type CharTwoFieldParamsType is derived from 
FieldParamsType and is used for encoding parameters of a 
characteristic two field. It is again an abstract type and will be 
extended by specialized types for trinomial and pentanomial base 
fields. F2m Gaussian Normal Base fields are not supported by this 
specification to relieve interoperability. Common to both 
specialized types is the element M, the extension degree of the 
field. 
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The XML Schema type TnBFieldParamsType is derived from the 
CharTwoFieldParamsType and is used for encoding trinomial base 
fields. It adds the single element K, which represents the integer 
k, where zim + x^k + 1 is the reduction polynomial. 


The XML Schema type PnBFieldParamsType is derived from the 
CharTwoFieldParamsType and is used for encoding pentanomial base 
fields. It adds the three elements K1, K2 and K3, which represent 
the integers kl, k2 and k3 respectively, where x^m + x^k3 + x^k2 + 
x^k1 + 1 is the reduction polynomial. 


The XML Schema type OddCharExtensionFieldParamsType is derived from 
the FieldParamsType and is used for encoding parameters of an odd 
characteristic extension field. This type contains two elements: M, 
which represents the extension degree of the field m, and W, which 
represents the integer w, where zim - w is the reduction polynomial. 


Schema Definition: 
<xs:complexType name="FieldParamsType" abstract="true"/> 


<xs:complexType name="PrimeFieldParamsType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:FieldParamsType"> 
<xs:seguence> 
<xs:element name="P" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


<xs:complexType name="CharTwoFieldParamsType" abstract="true"> 
<xs:complexContent> 
<xs:extension base="ecdsa:FieldParamsType"> 
<xs:sequence> 
<xs:element name="M" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


<xs:complexType name="OddCharExtensionFieldParamsType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:FieldParamsType"> 
<xs:sequence> 
<xs:element name="M" type-"xs:positiveInteger"/> 
<xs:element name="W" type-"xs:positiveInteger"/> 
</xs:sequence> 
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</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


<xs:complexType name="TnBFieldParamsType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:CharTwoFieldParamsType"> 
<xs:seguence> 
<xs:element name="K" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


<xs:complexType name="PnBFieldParamsType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:CharTwoFieldParamsType"> 
<xs:seguence> 
<xs:element name="K1" type-"xs:positiveInteger"/> 
<xs:element name="K2" type-"xs:positiveInteger"/> 
<xs:element name="K3" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


DTD Definition: 


<!ELEMENT FieldParams (P | (M, K) | (M, K1, K2, K3) | (M, W))> 
<!ELEMENT P (#PCDATA) > 
<!ELEMENT M (#PCDATA) > 
<!ELEMENT K (#PCDATA) > 
<!ELEMENT K1 (#PCDATA) > 
<!ELEMENT K2 (#PCDATA) > 
<!ELEMENT K3 (#PCDATA) > 
<!ELEMENT W (#PCDATA) > 


3.4.2.2. Curve Parameters 


The element CurveParams is used for encoding parameters of the 
elliptic curve. The corresponding XML Schema type CurveParamsType 
bears the elements A and B representing the coefficients a and b of 
the elliptic curve. According to the algorithm specified in annex 
A3.3 of [X9.62], the optional element Seed contains the value used to 
derive the coefficients of a randomly generated elliptic curve. 
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Schema Definition: 


<xs:complexType name="CurveParamsType"> 
<xs:sequence> 
<xs:element name="A" type="ecdsa:FieldElemType"/> 
<xs:element name="B" type="ecdsa:FieldElemType"/> 
<xs:element name="Seed" type="xs:hexBinary" minOccurs="0"/> 
</xs:sequence> 
</xs:complexType> 


DTD Definition: 


<!ELEMENT CurveParams (A, B, Seed?)> 
<!ELEMENT A EMPTY> 

<!ATTLIST A Value CDATA #REQUIRED> 
<!ELEMENT B EMPTY> 

<!ATTLIST B Value CDATA #REQUIRED> 
<!ELEMENT Seed (#PCDATA) > 


3.4.2.3. Base Point Parameters 


The element BasePointParams is used for encoding parameters regarding 
the base point of the elliptic curve. BasePoint represents the base 
point itself, Order provides the order of the base point, and 
Cofactor optionally provides the cofactor of the base point. 


Schema Definition: 


<xs:complexType name="BasePointParamsType"> 
<xs:sequence> 
<xs:element name="BasePoint" type="ecdsa:ECPointType"/> 
<xs:element name="Order" type-"xs:positiveInteger"/> 
<xs:element name-"Cofactor" type="xs:positivelInteger" 
minOccurs="0"/> 
</xs:sequence> 
</xs:complexType> 


DTD Definition: 


<!ELEMENT BasePointParams (BasePoint, Order, Cofactor?)> 
<!ELEMENT BasePoint (X, Y)?> 

<!ELEMENT Order (#PCDATA) > 

<!ELEMENT Cofactor (#PCDATA) > 
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3.4.3. EC Points 


The XML Schema type ECPointType is used for encoding a point on the 
elliptic curve. It consists of the subelements X and Y, providing 
the x and y coordinates of the point. Point compression 
representation is not supported by this specification for the sake of 
simple design. 


The point at infinity is encoded by omitting both elements X and Y. 


The subelements X and Y are of type FieldElemType. This is an 
abstract type for encoding elements of the elliptic curves underlying 
field and is extended by specialized types for prime field elements 
and characteristic two field elements. 


The XML Schema type PrimeFieldElemType is used for encoding prime 
field elements. It contains a single attribute named Value whose 
value represents the field element as an integer. 


The XML Schema type CharTwoFieldElemType is used for encoding 
characteristic two field elements. It contains a single attribute 
named Value whose value represents the field element as an octet 
string. The octet string must be composed as shown in paragraph 2 of 
section 4.3.3 of [X9.62]. 


The XML Schema type OddCharExtensionFieldElemType is used for 
encoding odd characteristic extension field elements. It contains a 
Single attribute named Value whose value represents the field element 
as an integer. The integer must be composed as shown in section 
5.3.3 of [IEEE1363a]. 


Schema Definition: 


<xs:complexType name-"ECPointType"> 
<xs:seguence minOccurs="0"> 
<xs:element name-"X" type-"ecdsa:FieldElemType"/> 
<xs:element name="Y" type-"ecdsa:FieldElemType"/> 
</xs:sequence> 
</xs:complexType> 
<xs:complexType name="FieldElemType" abstract="true"/> 
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<xs:complexType name="PrimeFieldElemType"> 
<xs:complexContent> 
<xs:extension base-"ecdsa:FieldElemType"> 
<xs:attribute name="Value" type-"xs:nonNegativeInteger" 
use-"reguired"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


<xs:complexType name-"CharTwoFieldElemType"> 
<xs:complexContent> 
<xs:extension base-"ecdsa:FieldElemType"> 
<xs:attribute name="Value" type-"xs:hexBinary" 
use-"reguired"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


<xs:complexType name-"OddCharExtensionFieldElemType"> 
<xs:complexContent> 
<xs:extension base-"ecdsa:FieldElemType"> 
<xs:attribute name="Value" type-"xs:nonNegativeInteger" 
use-"reguired"/> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


4. Security Considerations 
Implementers should ensure that appropriate security measures are in 


place when they deploy ECDSA within XMLDSIG. In particular, the 
security of ECDSA reguires careful selection of both key sizes and 


elliptic curve domain parameters. Selection guidelines for these 
parameters and some specific recommended curves that are considered 
safe are provided in [X9.62], [FIPS-186-2], and [SEC2]. For further 


security discussion, see [XMLDSIG]. 
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Appendix A. Aggregate XML Schema 


<?xml version-"1.0" encoding-"UTF-8"?> 

<xs:schema 
targetNamespace="http://www.w3.org/2001/04/xmldsig-more#" 
xmlns:ecdsa="http://www.w3.org/2001/04/xmldsig-more#" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified" 
version="0.2"> 


<!--ECDSA key value root element--> 


2005 


<xs:element name="ECDSAKeyValue" type-"ecdsa:ECDSAKeyValueType"/> 


<xs:complexType name="ECDSAKeyValueType"> 
<xs:sequence> 
<xs:element name="DomainParameters" 
type="ecdsa:DomainParamsType" minOccurs="0"/> 
<xs:element name-"PublicKey" type-"ecdsa:ECPointType"/> 
</xs:seguence> 
</xs:complexType> 


<!--EC domain parameters--> 


<xs:complexType name="DomainParamsType"> 
<xs:choice> 
<xs:element name="ExplicitParams" 
type="ecdsa:ExplicitParamsType"/> 
<xs:element name="NamedCurve"> 
<xs:complexType> 


<xs:attribute name="URN" type-"xs:anyURI" use-"reguired"/> 


</xs:complexType> 
</xs:element> 
</xs:choice> 
</xs:complexType> 
<xs:complexType name-"FieldParamsType" abstract-"true"/> 


<xs:complexType name-"PrimeFieldParamsType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:FieldParamsType"> 
<xs:seguence> 
<xs:element name="P" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<xs:complexType name="CharTwoFieldParamsType" abstract="true"> 
<xs:complexContent> 
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<xs:extension base="ecdsa:FieldParamsType"> 
<xs:seguence> 
<xs:element name="M" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<xs:complexType name="OddCharExtensionFieldParamsType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:FieldParamsType"> 
<xs:sequence> 
<xs:element name="M" type-"xs:positiveInteger"/> 
<xs:element name="W" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<xs:complexType name="TnBFieldParamsType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:CharTwoFieldParamsType"> 
<xs:sequence> 
<xs:element name="K" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<xs:complexType name="PnBFieldParamsType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:CharTwoFieldParamsType"> 
<xs:sequence> 
<xs:element name="K1" type-"xs:positiveInteger"/> 
<xs:element name="K2" type-"xs:positiveInteger"/> 
<xs:element name="K3" type-"xs:positiveInteger"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<xs:complexType name="ExplicitParamsType"> 
<xs:sequence> 
<xs:element name="FieldParams" type="ecdsa:FieldParamsType"/> 
<xs:element name="CurveParams" type="ecdsa:CurveParamsType"/> 
<xs:element name="BasePointParams" 
type="ecdsa:BasePointParamsType"/> 
</xs:sequence> 
</xs:complexType> 
<xs:complexType name="CurveParamsType"> 
<xs:sequence> 
<xs:element name="A" type="ecdsa:FieldElemType"/> 
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<xs:element name="B" type="ecdsa:FieldElemType"/> 
<xs:element name="Seed" type="xs:hexBinary" minOccurs="0"/> 
</xs:sequence> 
</xs:complexType> 
<xs:complexType name="BasePointParamsType"> 
<xs:seguence> 
<xs:element name="BasePoint" type-"ecdsa:ECPointType"/> 
<xs:element name="Order" type-"xs:positiveInteger"/> 
<xs:element name-"Cofactor" type="xs:positivelInteger" 
minOccurs="0"/> 
</xs:sequence> 
</xs:complexType> 


<!--EC point--> 


<xs:complexType name="ECPointType"> 
<xs:sequence minOccurs="0"> 
<xs:element name="X" type="ecdsa:FieldElemType"/> 
<xs:element name="Y" type="ecdsa:FieldElemType"/> 
</xs:sequence> 
</xs:complexType> 


<!--Field element—-> 


<xs:complexType name="FieldElemType" abstract="true"/> 
<xs:complexType name="PrimeFieldElemType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:FieldElemType"> 
<xs:attribute name="Value" type-"xs:nonNegativeInteger" 
use="required"/> 


</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<xs:complexType name="CharTwoFieldElemType"> 
<xs:complexContent> 
<xs:extension base="ecdsa:FieldElemType"> 
<xs:attribute name="Value" type-"xs:hexBinary" 
use-"reguired"/> 


</xs:extension> 
</xs:complexContent> 
</xs:complexType> 
<xs:complexType name-"OddCharExtensionFieldElemType"> 
<xs:complexContent> 
<xs:extension base-"ecdsa:FieldElemType"> 
<xs:attribute name="Value" type-"xs:nonNegativeInteger" 
use-"reguired"/> 
</xs:extension> 
</xs:complexContent> 
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</xs:complexType> 
</xs:schema> 


Appendix B. 


<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ATTLIS 
<! ELEMEN 
<!ATTLIS 
<!ELEMEN 
<!ELEMEN 
<!ATTLIS 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMEN 
<!ATTLIS 
<! ELEMEN 
<!ATTLIS 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 
<!ELEMENT 


Blake-Wilson, 


Aggregate DTD 


ECDSAKeyValue (DomainParameters?, PublicKey)> 
PublicKey (X, Y)?> 

X EMPTY> 

X Value CDATA #REQUIRED> 

Y EMPTY> 

Y Value CDATA #REQUIRED> 

DomainParameters (ExplicitParams NamedCurve)> 
NamedCurve EMPTY> 

NamedCurve URN CDATA #REQUIRED> 


April 2005 


ExplicitParams (FieldParams, CurveParams, BasePointParams)> 


FieldParams (P | (M, K) | (M, Kl, K2, K3) | (M, W))> 
P (#PCDATA) > 
M (#PCDATA) > 
W (#PCDATA) > 
K (#PCDATA) > 


K1 (#PCDATA) > 

K2 (#PCDATA) > 

K3 (#PCDATA) > 

CurveParams (A, B, Seed?)> 
A EMPTY> 

A Value CDATA #REQUIRED> 

B EMPTY> 

B Value CDATA #REQUIRED> 
Seed (#PCDATA) > 
BasePointParams (BasePoint, Order, Cofactor?)> 
BasePoint (X, Y)?> 

Order (#PCDATA) > 

Cofactor (#PCDATA) > 
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